So, you watch for advisories, deploy countermeasures (e.g., change firewall and IDS rules) or shut down vulnerable services, patch applications, restore services.  You detect compromises, limit damages, assess the damage, repair, recover, and attempt to prevent them again.  Tomorrow you start again, and again, and again.  Is it worth it?  What difference does it make?  Who cares anymore? 

If you’re sick of it, you may just be getting fatigued.

If you don’t bother defending anymore because you think there’s no point to this endless threadmill, you may be suffering from learned helplessness.  Some people even consider that if you only passively wait for patches to be delivered and applied by software update mechanisms, you’re already in the “learned helplessness category”.  On the other hand, tracking every vulnerability in the software you use by reading BugTraq, Full Disclosure, etc…, the moment that they are announced, and running proof of concept code on your systems to test them isn’t for everyone;  there are diminishing returns, and one has to balance risk vs energy expenditure, especially when that energy could produce better returns.  Of course I believe that using Cassandra is an OK middle ground for many, but I’m biased.

The picture may certainly look bleak, with talk of “perpetual zero-days”.  However, there are things you can do (of course, as in all lists not every item applies to everyone):

• Don’t be a victim;  don’t surrender to helplessness.  If you have limited energy to spend on security (and who doesn’t have limits?), budget a little bit of time on a systematic and regular basis to stay informed and make progress on tasks you identify as important;  consider the ones listed below.
• Don’t be a target.  Like or hate Windows, running it on a desktop and connecting to the internet is like having big red circles on your forehead and back.  Alternatives I feel comfortable with for a laptop or desktop system are Ubuntu Linux and MacOS X (for now;  MacOS X may become a greater target in time).  If you’re stuck with Windows, consider upgrading to Vista if you haven’t already;  the security effort poured into Vista should pay off in the long run.  For servers, there is much more choice, and Windows isn’t such a dominant target. 
• Reduce your exposure (attack surface) by:
  • Browsing the web behind a NAT appliance when at home, in a small business, or whenever there’s no other firewall device to protect you.  Don’t rely only on a software firewall;  it can become disabled or get misconfigured by malware or bad software, or be too permissive by default (if you can’t or don’t know how to configure it).
  • Using the NoScript extension for Firefox (if you’re not using Firefox, consider switching, if only for that reason).  JavaScript is a vector of choice for desktop computer attacks (which is why I find the HoneyClient project so interesting, but I digress).  JavaScript can be used to violate your privacy* or take control of your browser away from you, and give it to website authors, advertisers on those sites, or to the people who compromised those sites, and you can bet it’s not always done for your benefit (even though JavaScript enables better things as well).  NoScript gives you a little control over browser plugins, and which sources are allowed to run scripts in your browser, and attempts to prevent XSS exploits.
  • Turning off unneeded features and services (OK, this is old advice, but it’s still good).

• Use the CIS benchmarks, and if evaluation tools are available for your platform, run them.  These tools give you a score, and even as silly as some people may think this score is (reducing the number of holes in a ship from 100 to 10 may still sink the ship!), it gives you positive feedback as you improve the security stance of your computers.  It’s encouraging, and may lift the feeling that you are sinking into helplessness.  If you are a Purdue employee, you have access to CIS Scoring Tools with specialized features (see this news release).  Ask if your organization also has access and if not consider asking for it (note that this is not necessary to use the benchmarks).

• Use the NIST security checklists (hardening guides and templates).  The NIST’s information technology laboratory site has many other interesting security papers to read as well.

• Consider using Thunderbird and the Enigmail plugin for GPG, which make handling signed or encrypted email almost painless.  Do turn on SSL or TLS-only options to connect to your server (both SMTP and either IMAP or POP) if it supports it.  If not, request these features from your provider.  Remember, learned helplessness is not making any requests or any attempts because you believe it’s not ever going to change anything.  If you can login to the server, you also have the option of SSH tunneling, but it’s more hassle.

• Watch CERIAS security seminars on subjects that interest you.

• If you’re a software developer or someone who needs to test software, consider using the ReAssure system as a test facility with configurable network environments and collections of VMware images (disclosure: ReAssure is my baby, with lots of help from other CERIAS people like Ed Cates).

Good luck!  Feel free to add more ideas as comments.

*A small rant about privacy, which tends to be another area of learned helplessness: Why do they need to know?  I tend to consider all information that people gather about me, that they don’t need to know for tasks I want them to do for me, a (perhaps very minor) violation of my privacy, even if it has no measurable effect on my life that I know about (that’s part of the problem—how do I know what effect it has on me?).  I like the “on a need to know basis” principle, because you don’t know which selected (and possibly out of context) or outdated information is going to be used against you later.  It’s one of the lessons of life that knowledge about you isn’t always used in legal ways, and even if it’s legal, not everything that’s legal is “Good” or ethical, and not all agents of good or legal causes are ethical and impartial or have integrity.  I find the “you’ve got nothing to hide, do you?” argument extremely stupid and irritating—and it’s not something that can be explained in a sentence or two to someone saying that to you.  I’m not against volunteering information for a good cause, though, and I have done so in the past, but it’s rude to just take it from me without asking and without any explanation, or to subvert my software and computer to do so. 

The Cassandra system has been much more successful and long lasting than I first imagined.  Being inexperienced at the time, there were some things I got wrong, such as deleting inactive accounts (I stopped that very quickly as it made many people unhappy or unwilling to use the service), or deleting accounts that bounced several emails (several years ago this was changed to simply invalidating the email address).  Recently I improved it by adding GPG signatures.  Email notifications from Cassandra are now cryptographically signed. The public key is available on the standard public key servers, such as the MIT server.

Things can still be improved

I initially envisioned profiles as being updated regularly, perhaps with automated tools listing the applications installed on a system.  I also thought that there were many applications without vulnerability entries in MITRE’s CVE, the National Vulnerability Database (NVD, used to be named ICAT), or Secunia so I needed to let people enter product and vendor names that weren’t linked to any vulnerabilities.  However, I found that there was little correlation between the names of products in these sources, as well as between those provided by scanning tools or entered manually by users.  ICAT in particular used to be quite bad for using inconsistent or misspelled names.  Secunia does not separate vendor names from products and uses different names than the NVD, so Cassandra has to guess which is which based on already known vendor and product names.  Because of this, Secunia entries may need reparsing when new names are learned.  So, users could get a false sense of security by entering the name of the products they use, but never get notified because of a mismatch!  On top of it, bad names are listed by the autocomplete feature, so users can be mislead by someone else’s mistakes or misfortune.  A Cassandra feature that helped somewhat with this problem was the notion of canonical and variant names.  All variants point to a single canonical name for a vendor or a product.  However, these need to be entered manually and maintained over time, so I didn’t enter many.

It gets worse.  Profiles are quite static in practice;  this leads to other problems.  Companies merge, get bought or otherwise change names. Sometimes companies also decide to change the names of their products for other reasons, or names are changed in the NVD. So, profiles can silently drift off-course and not give the alerts needed. All these factors result in product or vendor names in Cassandra that don’t point to any vulnerability entries.  I call these names “orphans”;  I recently realized that Cassandra contained hundreds of orphaned names.

And they will be improved

I am planning on implementing two new features in Cassandra:  Profile auto-correction and product name vetting.

• Auto-correction: If Cassandra recognizes a name change in the NVD or Secunia, or if it changes the way it recognizes vendor names from products in Secunia, it will attempt to change matching entries in your profiles.
• Vetting: all the product names in Cassandra will be verified to point to at least one entry in the NVD or Secunia; those that don’t and can’t be updated will get deleted. This means that when you create a new profile, Cassandra won’t suggest an “orphaned” name. If your profile contains an orphaned name that gets deleted, you should receive an email if you have email notifications turned on.

Note that you should still verify your profiles periodically, because Cassandra will not detect all name changes—this is difficult because a name change may look just like a new product.  If you have a product name that isn’t in Cassandra, I suggest using the keywords feature.  Cassandra will then search the title and description of the entries to find matches (note to self: pehaps keywords should search product and vendor names as well—that would help catch all variants of a name.  Also, consider using string matching algorithms to recognize names).

[tags]the Internet[/tags]
Satire is sometimes a great way to get a point across.  Or multiple points.  I think this little clip is incredibly funny and probably insightful.

[tags]news, cell phones, reports, security vulnerabilities, hacking, computer crime, research priorities, forensics, wiretaps[/tags]
The Greek Cell Phone Incident
A great story involving computers and software, even though the main hack was against cell phones:
IEEE Spectrum: The Athens Affair.  From this we can learn all sorts of lessons about how to conduct a forensic investigation, retention of logs, wiretapping of phones, and more.

Now, imagine VoIP and 802.11 networking and vulnerabilities in routers and…. —the possibilities get even more interesting.  I suspect that there’s a lot more eavesdropping going on than most of us imagine, and certainly more than we discover.

NRC Report Released
Last week, the National Research Council announced the release of a new report: Towards a Safer and More Secure Cyberspace.  The report is notable in a number of ways, and should be read carefully by anyone interested in cyber security.  I think the authors did a great job with the material, and they listened to input from many sources.

There are 2 items I specifically wish to note:

1. I really dislike the “Cyber Security Bill of Rights” listed in the report.  It isn’t that I dislike the goals they represent—those are great.  The problem is that I dislike the “bill of rights” notion attached to them.  After all, who says they are “rights”?  By what provenance are they granted?  And to what extremes do we do to enforce them?  I believe the goals are sound, and we should definitely work towards them, but let’s not call them “rights.”
2. Check out Appendix B.  Note all the other studies that have been done in recent years pointing out that we are in for greater and greater problems unless we start making some changes.  I’ve been involved with several of those efforts as an author—including the PITAC report, the Infosec Research Council Hard Problems list, and the CRA Grand Challenges. Maybe the fact that I had no hand in authoring this report means it will be taken seriously, unlike all the rest.   More to the point, people who put off the pain and expense of trying to fix things because “Nothing really terrible has happened yet” do not understand history, human nature, or the increasing drag on the economy and privacy from current problems.  The trends are fairly clear in this report: things are not getting better.

Evolution of Computer Crime
Speaking of my alleged expertise at augury, I noted something in the news recently that confirmed a prediction I made nearly 8 years ago at a couple of invited talks: that online criminals would begin to compete for “turf.”  The evolution of online crime is such that the “neighborhood” where criminals operate overlaps with others.  If you want the exclusive racket on phishing, DDOS extortion, and other such criminal behavior, you need to eliminate (or absorb) the competition in your neighborhood.  But what does that imply when your “turf” is the world-wide Internet?

The next step is seeing some of this spill over into the physical world.  Some of the criminal element online is backed up by more traditional organized crime in “meat space.”  They will have no compunction about threatening—or disabling—the competition if they locate them in the real world.  And they may well do that because they also have developed sources inside law enforcement agencies and they have financial resources at their disposal.  I haven’t seen this reported in the news (yet), but I imagine it happening within the next 2-3 years.

Of course, 8 years ago, most of my audiences didn’t believe that we’d see significant crime on the net—they didn’t see the possibility.  They were more worried about casual hacking and virus writing.  As I said above, however, one only needs to study human nature and history, and the inevitability of some things becomes clear, even if the mechanisms aren’t yet apparent.

The Irony Department
GAO reported a little over a week ago that DHS had over 800 attacks on their computers in two years.  I note that the report is of detected attacks.  I had one top person in DC (who will remain nameless) refer to DHS as “A train wreck crossed with a nightmare, run by inexperienced political hacks” when referring to things like TSA, the DHS cyber operations, and other notable problems.  For years I (and many others) have been telling people in government that they need to set an example for the rest of the country when it comes to cyber security.  It seems they’ve been listening, and we’ve been negligent.  From now on, we need to stress that they need to set a good example.

[posted with ecto]

[tags]diversity, complexity, monocultures[/tags]
In my last post, I wrote about the problems brought about by complexity.  Clearly, one should not take the mantra of “simplification” too far, and end up with a situation where everything is uniform, simple, and (perhaps) inefficient.  In particular, simplification shouldn’t be taken to the point where diversity is sacrificed for simple uniformity.

Nature penalizes monocultures in biological systems.  Monocultures are devastated by disease and predators because they have insufficient diversity to resist.  The irish potato famine, the emerald ash borer, and the decimation of the Aztecs by smallpox are all examples of what happens when diversity is not present. Nature naturally promotes diversity to ensure a robust population.

We all practice diversity in our everyday lives.  Diversity of motor vehicles, for instance supports fitness for purpose—a Camero, is not useful for hauling dozens of large boxes of materials.  For that, we use a truck.  However, for one person to get from point A to point B in an economical fashion, a truck is not the best choice.  It might be cheaper and require less training to use the same vehicle for everything, but there are advantages to diversity.  Or tableware—we have (perhaps) too many forks and spoon types in a formal placesetting, but try eating soup with a fork and you discover that some differentiation is useful!

In computing, competition has resulted in advances in hardware and software design.  Choice among products has kept different approaches moving forward.  Competition for research awards from DARPA and NSF has encouraged deeper thought and more focused proposals (and resultant development).  Diversity in operating systems and programming languages brought many advancements in the era 1950-2000.  However, expenses and attempts to cut staff have led to widespread homogenization of OS, applications, and languages over approximately the last decade.

Despite the many clear benefits of promoting diversity, too many organizations have adopted practices that prevent diversity of software and computing platforms.  For example, the OMB/DoD Common Desktop initiative is one example where the government is steering personnel towards a monoculture that is more maintainable day-to-day, but which is probably more vulnerable to zero-day attacks and malware.

Disadvantages of homogeneity:

• greater susceptibility to zero-day vulnerabilities and attacks
• “box canyon” effect of being locked into a vendor for future releases
• reduced competition to improve quality
• reduced competition to reduce price and/or improve services
• reduced number of algorithms and approaches that may be explored
• reduced fitness for particular tasks
• simpler for adversaries to map and understand networks and computer use
• increased likelihood that users will install unauthorized software/hardware from outside sources

Advantages of homogeneity:

• larger volume for purchases
• only one form of tool, training, etc needed for support
• better chance of compatible upgrade path
• interchangeability of users and admins
• more opportunities for reuse of systems

Disadvantages of heterogeneity:

• more complexity so possibly more vulnerabilities
• may not be as interoperable
• may require more training to administer
• may not be reusable to the same extent as homogeneous systems

Advantages of heterogeneity:

• when at a sufficient level greater resistance to malware
• highly unlikely that all systems will be vulnerable to a single new attack
• increased competition among vendors to improve price, quality and performance
• greater choice of algorithms and tools for particular tasks
• more emphasis on standards for interoperability
• greater likelihood of customization and optimization for particular tasking
• greater capability for replacement systems if a vendor discontinues a product or support

Reviewing the above lists makes clear that entities concerned with self-continuation and operation will promote diversity, despite some extra expense and effort.  The potential disadvantages of diversity are all things that can be countered with planning or budget.  The downsides of monocultures, however, cannot be so easily addressed.

Dan Geer wrote an interesting article for Queue Magazine about diversity, recently.  It is worth a read.

The simplified conclusion: diversity is good to have.